1. Field of the Invention
This invention relates to the field of I/O reconfigurable data processing systems. More specifically it relates to the making of changes to the input/output (I/O) configuration of such a system with minimal disruption to the system's operation.
2. Background Art
Data processing systems in the field of art of the present invention typically comprise a central processor complex attached to one or more control units and their associated I/O devices in an I/O subsystem (or with other processor complexes), and central storage; and the CPU further comprises an Arithmetic Logical Unit (ALU), registers, high speed buffers, and the Processor Controller. Such systems are typically managed by a control program such as IBM's MVS/ESA.
Since such a system has a high degree of modularity, it is a routine event to add, delete, or exchange control units, I/O devices, or change channel path configurations, in the system. A particular I/O configuration must be defined both to the system's channel subsystem and operating system software, and a change to an I/O configuration occasioned by the addition, deletion, or exchange of an I/O device must reflected in a change to the hardware and software definition.
In the past it has been a matter of some difficulty to change a system's I/O configuration without disrupting active processing or the system. A normal course of events would be to establish a new set of definitions, stop processing of work on the system, add, delete, or change the devices and controllers by performing the physical connection, disconnection, or reconnection, then power on reset (POR) the hardware and initial program load (IPL) the operating system to reestablish the correct hardware and software definitions, and again start the processing of work.
This was recognized to be unacceptably disruptive and expensive, requiring as it does that the system be idle for a possibly long time period while the reconfiguration is performed. Therefore, schemes were devised to reduce the impact on system processing: one such scheme involved "over-defining" an I/O configuration--i.e., setting up definitions (control blocks) for nonexistent (at present) devices, which could then be utilized later when new devices are added. However this scheme has its limitations: the number of reserved definitions is a largely matter of intelligent guess work; space is wasted by the reservation of the unused control blocks; the scheme allows for the addition, not the deletion of device definitions; and certain types of changes (such as the incorrect specification of device's "type") still required a system reinitialization.
Other schemes provided for the dynamic addition of a device definition without pre-reservation of control blocks, but did not deal with device definition deletion since deletion poses the additional problem of the treatment of ongoing system work making use of the device to be deleted--again, the traditional method of dealing with this situation was to "quiesce" the system (completing ongoing work without starting new work) so that the device could be disconnected, and device definition deleted, without adversely affecting ongoing processing. Still other schemes dealt with changing the characteristics of existing device definitions again leaving unresolved the matter of whether or not active work must stop, and how to deal with device additions, or deletions.